Preface to the Second Edition
This book, in a word, is about documentation. Sounds boring, doesn’t it?
Documentation—the collection of documents prepared over the course of a project—is, in many ways, the underbelly of web design. After all, documents usually appear on paper and end up sitting on a shelf where no one reads them. How cool could that be?
But anyone who has designed a web site knows that documentation can make or break the project, that it moves the process along by capturing the design concept and helps project team members communicate with each other. Web design documents—or deliverables, as they’re sometimes called—also serve as milestones, marking progress in an otherwise seemingly interminable process. They’re historical, allowing people who come to a project later to get up to speed on the decisions made by earlier project teams.
In short, a document captures an idea. Perhaps this is a little existential for the web design business but, getting down to brass tacks, if we can’t communicate an idea effectively, how can we hope to create a web site around it?
On the surface, this book will help you improve your documentation, providing advice on how to plan your deliverables and use them effectively in meetings and on projects. In the course of doing so, it will also attempt to uncover what makes a document good, and help you recognize the difference between a bad document and a bad idea.
Is This Book Right for You?
This book is written for people who make deliverables, use deliverables, and approve deliverables as part of the web design process.
• Making deliverables: Whether you’re new to web design or have been doing it for years, if you’re making deliverables, this book will help keep your efforts on track. It will either introduce you to new techniques for planning or presenting deliverables, or provide a refresher if it’s been awhile since the last time you had to crank out a deck of wireframes, for example.
• Using deliverables: It may not be your responsibility to create the site map, but you’re the one who has to consult it for the next several days or weeks or months as you migrate content from the existing site to this new structure. Or perhaps you’re a developer who needs to write code for making the web site behave as documented in the wireframes. Or maybe you’re the client, and you face an uphill battle in your organization in selling the idea of this redesign—those personas will sure come in handy, but you want to make sure they’re airtight. This book will help you make sure you know what you’re getting and prepare you for conversations with the user experience designers on your team.
• Approving deliverables: If the buck stops with you, you’ll want to make sure all the i’s are dotted and t’s are crossed. As the client or main stakeholder—let’s face it, the money person—you have a lot riding on these documents. They’re essential for moving the project along, judging whether you’re getting your money’s worth, and keeping the design team honest. This book can help you make sure you know what to expect from your team’s deliverables.
“But I Don’t Use Deliverables”
Really? You’ve never written an email or drawn something up on a whiteboard? You’ve never thrown together a sketch to get some feedback? You’ve never assembled a flowchart in a diagramming application just to make sure you have all the steps covered?
It’s true that some software methodologies eschew creating anything other than assets that will go into the final product. At least, that’s how some people interpret those methodologies.
Every design methodology, however, entails drawing, sketching, explaining, or modeling. Every design process acknowledges the value of creating pictures or representations of the final product as a means for working through the problem. Every good designer takes a moment to envision the problem, to understand (at whatever extent is feasible) what the requirements and constraints are.
Even if you’re not creating formal, multipage deliverables, you still need to describe complicated ideas, or work out a design problem, or tell a story about your approach. The diagrams and documents in this book let you do that. They’re described in a way that allows for varying levels of effort: from 15 minutes in front of a whiteboard to longer periods of time to dot the i’s and cross the t’s.
What’s in This Book?
The second edition of this book tries to build on philosophy and objectives of the first edition:
• It doesn’t cover every deliverable. This book discusses five common diagrams created as part of the web design process, and deliverables—the ones you won’t be able to avoid if you spend any time at all in this business. These are user experience deliverables, so if you’re looking for advice on creating entity relationship diagrams or unified modeling language diagrams, you might want to go elsewhere. There are countless documents for user experience work that this book could have addressed, but many are not common, or they’re proprietary, or they’ve been discussed elsewhere.
• It doesn’t care what methodology you use. Methods come and go, but documents remain more or less consistent. One of the central assumptions of this book is that anyone should be able to use it, regardless of the methodology they use. That being said, it’s difficult to write about documentation without any sense of timing or dependency, so I will make a few methodological assumptions. These assumptions provide structure for the book, but they won’t render it useless if you’re using a different method.
• It’s a how-to book, but not a software book. This book will help you make better deliverables. It will help you present those deliverables better to your clients and team members. It will even help you anticipate risks in creating and sharing deliverables. But it will not tell you how to use software applications to make those deliverables. Different people prefer different tools, but the choice of tool should have little impact on the message and purpose of your documentation.
• It’s a cookbook. Each chapter in this book is a recipe for working with a different kind of document, and you’ll have your own ideas about what makes a dish work and what doesn’t. Feel free to add notes in the margin. You may even find that a technique described for one kind of document works well for a different kind of document. Although the book tries to make each chapter self-contained, you may find inspiration for one kind of deliverable in other chapters.
Why a Second Edition?
Believe me, I ask myself this question every day. Here are some of the answers I came up with:
• The web has changed. The web can do a lot more in 2010 than it could in 2005. The role of the web in our lives has changed. Our means for accessing the web have changed. As pervasive as it is, it’s hard to think of it as a “channel,” and as flexible as it is, it’s hard to think of it as a “medium.” If nothing else, the book needed to accommodate the new perspectives, new technologies, and new role of the web.
• Design methodologies have changed. For a while there, the web design process seemed to stagnate. In the last couple years, however, a renewed interest in prototyping, collaborative design, and sketching has reinvigorated web design. It’s becoming easier to model things, and the technologies available to designers allow them to iterate faster.
• I’ve changed. Not that you care, but my own thinking on how to prepare and talk about design documentation has changed in the last five years. Witnessing the evolution of the web and of the practice of design, and working with many designers to help them refine their own documentation practices and skills, has encouraged me to evaluate my own place relative to design. I’ve had the extraordinary opportunity to work closely with a business partner, Nathan Curtis, who thinks about this stuff even more deeply than I do. We’ve built a company of people who also value good visual storytelling, and I learn something new from them every day.
Changes from the First Edition
So, what’s different?
The Format
The first thing you’ll notice is that this is a bigger book. Inspired by a textbook for making comics, Drawing Words & Writing Pictures, I sought a larger landscape format to accommodate larger drawings. I always wanted fat margins to give you, the reader, the opportunity to embellish the book with your own lessons learned, and the larger format affords one.
The Structure
One of the biggest problems with the first edition is that it treats every deliverable at an equal level. It positions a flowchart as a stand-alone deliverable on par with a competitive analysis. Reality suggests otherwise: Preparing comprehensive documents poses a different set of challenges than preparing a diagram. There is an inexorable push-and-pull between diagrams and deliverables, a tension that makes documentation challenging but also feeds the creative process. Discrete diagrams and multipage documents both tell stories, but they do so in different ways.
To that end, I’ve restructured the book into two sections:
• Design Diagrams contains chapters on Personas, Concept Models, Site Maps, Flowcharts, and Wireframes. Each of these is a separate, stand-alone diagram that needs a document around it to provide context.
• Design Deliverables contains chapters on Design Briefs (new!), Competitive Reviews, Usability Plans, and Usability Reports. These are multipage documents that tell extended stories, incorporating diagrams from the first part of the book.
Each section starts off with a “Basics” chapter to lay some groundwork for creating diagrams and deliverables, respectively.
The Content
I’ve rewritten many of the chapters, especially for the design diagrams. While the first edition laid great starting points for helping readers think through the preparation of design artifacts, there were opportunities to provide more concrete guidance.
The first edition became part of the curriculum in many academic programs for web design, interaction design, and information architecture. To that end, I’ve included exercises at the end of several chapters to facilitate the use of the book in those settings.
What’s missing
I took out a couple chapters: content inventory and screen designs.
• Content inventories remain valuable tools in the kit of a web designer, and I strongly believe that content must be a part of the design process. In recent years, content strategy has emerged (though like most design endeavors, it’s likely been there all along) and formalized the tools and techniques used to “design content.” Personally, I haven’t done a content audit since the first edition, and I had nothing to new to say.
• I also didn’t have anything new to say about screen designs, at least anything that isn’t being said better and more comprehensively elsewhere. There are some beautiful books on designing web sites, and how to talk to project teams about design.
What’s new
Lest you think removing a couple chapters diminishes the value of the book, let me take a moment to inventory what’s been added:
• New chapters on basics: One of the things that bothered me about the first edition was that while most advice was specific to individual deliverables, there were some points that covered all documentation. The new structure gives me a chance to add some chapters on basics for both diagrams and deliverables.
• New chapter on design briefs: One of the documents I regret leaving out of the first edition is the design brief. I’m glad I could remedy that.
• More illustrations: From the moment the first edition came out, I was disappointed with the small number of illustrations. In a book about pictures, there was a dearth of them. I’ve tried to remedy that in this edition.
• Advice from experts: Many chapters incorporate the opinions and practices from experts in our fields. These sidebars pose a question about a more advanced topic relating to the specific diagram or deliverable.
The Tone
Perhaps it’s my age or my evolving role relative to design, but I have less of an us-versus-them attitude. Being a designer in an organization whose culture evolved around something besides design (like a government agency, or a manufacturer, or a services business), it can be hard to feel a part of the designer culture. For years here in the Washington, DC area, the web design community thrived on a camaraderie that came from being a lone wolf inside organizations that usually didn’t know what to make of their “webmasters.” Our meet-ups were like support groups.
Much has changed.
As the web has become even more pervasive, and as everyone has begun to play a role in the design, construction, or maintenance of their organization’s web site, there’s a greater appreciation for the designer. The web designer has a new challenge, maybe even a greater and more important challenge than educating people about the web and user experience. That is to help everyone contribute to the design process, to establish a vision and help a multidisciplinary team realize it.
Pictures and Words, Words and Pictures
Communicating design is about combining words and pictures into a story that elaborates on a vision, describes a user experience, and remains meaningful in the context of a project. Web designers face new challenges every day (or similar challenges within dramatically different contexts), but we can think through those challenges and communicate potential solutions by combining words and pictures. So, whether you have to describe a new type of interaction, explain what kinds of content appear on the home page, summarize user research, or think through a complex navigation structure, you need to pick up a pen and start drawing and writing. This book, if it does nothing else, should help you think about the ways in which we combine these elements to tell those stories that address these and many other challenges.